An Introduction to Web Accessibility

As a parent, I've realized how challenging it can be to travel by train with a stroller. You can't simply take the stairs like you used to; instead, you must find elevators and the train doors designed for strollers and wheel chairs. When the elevator at the train station is broken—which, sadly, happens too often for my liking—the struggle begins. You have to carry the stroller in one hand and your child in the other. I can tell you from experience, this requires a great deal of effort and coordination to avoid a fall.

Another example is found in some children’s books that use low-contrast color schemes, such as black letters on a dark blue background or white letters on a yellowish one. The contrast is simply not strong enough to read when the lights are dimmed for a bedtime story. In these cases, you are left to interpret and invent the continuation of the story.

Even if you don’t have children, you will encounter many topics that involve accessibility issues. Consider language barriers, or how left-handed people often have to use products designed for right-handed users. For instance, why is a typical pair of scissors so problematic?

The EU Directive 2019/882, also known as the European Accessibility Act, requires private enterprises to make their digital offerings accessible to people using Assistive Technologies (AT) by 2025. Beyond these new regulations, countless people rely on AT to navigate the digital world. If your product is not accessible, you risk facing significant legal penalties and fines, and you also fail to reach the full potential of the market.

Spectrum of Impairments

When I first heard about web accessibility, I thought it only applied to people with visual impairments who struggle with digitalization. But this couldn't be further from the truth. There is a range of different accessibility issues we need to take into account. According to research:

• around 3 - 4 % have seeing disabilities – making it necessary to use screen readers, magnification software, and Braille-Displays.
• around 10 % have motoric disabilities – adaptive keyboards, voice command, and eye tracking will be used here.
• around 5 % have hearing issues – visual signs are necessary as well as transcripts and subtitles.
• around 10 % have cognitive impairments – voice reading, simple language, and design are important.
• some have speech disabilities – these people will have issues using common video call tools.

We realized that true web accessibility demands consideration of a broad spectrum of impairments: visual, cognitive, auditory, physical, and speech.

Web Content Accessibility Guidelines

Good that there are already some standards what we can use and we do not need to invent everything new. The WCAG (Web Content Accessibility Guidelines) developed by the World Wide Web Consortium (W3C) give us hints, how to do things right. Let’s start with it.

Semantic HTML and Landmark Regions

This is the basic of creating an accessible webpage. Use HTML elements that already carry a meaning about their content. Use <main> for the main content, use <nav> for navigation, use <aside> for a separate content. This improves the accessibility and helps screen readers to navigate between major sections. There is a broad range of HTML semantic elements, in the following, only some are mentioned. Click on the elements to see more details.

The list is for sure curious for you. You might know some more and others less. You should now know that landmark regions are the main navigational regions.

Accessibility Rich Internet Applications

Accessibility Rich Internet Applications (ARIA) is a set of attributes that enhance the accessibility of web content and applications for assistive technologies, particularly screen readers. ARIA consists of two primary categories: roles and properties.

ARIA Roles

They help to identify for screen readers how a specific area or element should behave. For example, there might be images that should act as a button. So in this case you would add role="button" to your HTML. Else, people using Screenreaders do not know, that they can click on the image! Since it is an image, you should also mention it, that you can click on it. There are quite a few ARIA widget roles. Click on the next element to display them.

A complete list can be found here: Link to Roles Categorization

ARIA Properties

Next to the ARIA role that defines an element to behave in a certain way, ARIA properties provide additional information about the purpose. They define especially the text of an element that is read by the screen reader and if an element is required, read-only or disabled. Click on the next element to see the most commonly used properties.

Often the question occurs: How does aria-describedby works? Here is a small example:

            <span id="errorDescription">Please enter a valid email address.</span>
            <input type="email" aria-describedby="errorDescription">

When the user tabs into this input element, the screen reader will announce the description from the <span> element with the ID "errorDescription."

Many more ARIA properties exist; the most up-to-date information is available at Link to Complete List of ARIA Properties

Keyboard Navigation

It's easy to take for granted that everyone uses a mouse, but for many people - those with visual impairments, motor limitations, or other reasons - navigating with a keyboard is the primary way they interact with the web.

One of the best ways to ensure good keyboard navigation is to use semantic HTML. Elements like links, buttons, and form fields (such as <input>, <select>, <textarea>) have built-in keyboard support. They're naturally part of the tab order and respond to common keyboard actions like Enter and Spacebar. On the other hand, structural or text content elements like <div>, <span>, <p>, and headings don't receive focus by default, but we can change that if needed.

That's where the tabindex attribute comes in. Think of tabindex as a way to control which elements are included in the keyboard navigation flow. Setting tabindex="0" on an element makes it focusable and puts it in the natural tab order. This is the way to go if you need to make something like a <div> act like a button or other interactive element. If you want to take an element out of the tab order, you use tabindex="-1".

A word of caution: avoid at the beginning positive tabindex values (like 1, 2, 3, etc.). They create a custom tab order that's really hard to manage if you insert new elements in the webpage. It will frustrate the keyboard user if the focus jumps not naturally to a random element further down in the webpage and then backwards.

Just making something focusable isn't the whole story. Users need a clear visual cue to know where the focus is. This is where the focus indicator comes in. It's usually a highlighted outline or a change in background color that appears around the focused element. When styling your focus indicator with CSS, make sure it has good contrast against the background so it's easy to see, especially for people with low vision. It's often a good idea to enhance the browser's default focus style rather than completely replacing it.

Here’s a basic example for your CSS file:

  <style>
  *:focus {
    outline: 3px solid #007bff; /* A nice blue outline */
    outline-offset: 2px; /* Gives it a little breathing room */
  }

  /* Fixes double outlines on some buttons */
  button:focus {
    outline: 3px solid #007bff;
  }
  button::-moz-focus-inner {
    border: 0;
  }
  </style>

Beyond the Tab key, there are other important keyboard interactions to consider. Arrow keys are used to navigate within things like menus, lists, and grids. Shift + Tab lets users move backward through the tab order. And the ESC key should always close dialogs, pop-ups, and things like cookie consent banners.

When you have interactive elements that appear dynamically, like modal dialogs, you need to manage focus carefully with JavaScript. When you open a modal dialog, immediately shift focus to the first interactive element inside it. When the modal closes, return focus to the element that triggered it. This is important to ensure a smooth workflow. Also, make sure focus is "trapped" inside the modal. This means that if a user keeps pressing Tab, the focus will cycle through the elements within the modal, and they won't accidentally tab out of it.

The best way to make sure everything works correctly is to test, it! Use your keyboard to navigate your website. Can you reach every interactive element? Is the focus indicator clear? Can you close all pop-ups with the Esc key? These simple tests can go a long way in making your website accessible to everyone.

Contrast

You'll frequently hear the term "contrast ratio," which measures the difference in luminance between two colors. The higher the contrast ratio, the greater the difference in brightness and the easier it is to read. For example, black text on a white background provides a very high contrast ratio of 21:1. The Web Content Accessibility Guidelines (WCAG) have specific standards for contrast to ensure content is readable for everyone. The minimum standard, also called level AA, requires a contrast ratio of at least 4.5:1 for normal text. For an even higher level of accessibility, the enhanced standard requires a contrast ratio of at least 7:1 for normal text.

You can verify sufficient contrast between foreground and background colors using a tool such as WebAIM's Contrast Checker, available at:

Link to WebAIM Contrast Checker .

Also a widely recommended idea is to develop a webpage using only grayscales. Designing in grayscale makes it much easier to assess contrast. If your design works well in grayscale, you're already a long way toward meeting WCAG contrast requirements. It's much simpler to check contrast between shades of grey than between various colors.

Responsiveness and Language

You might think that this has nothing to do with accessibility, but if the design is not responsive, the product cannot be used by a variety of different screen sizes, including smartphones, tablets or desktops. Also it is important for people with visual impairments that rely on screen magnifiers.

People with cognitive disabilities, like dyslexia, ADHD (Attention-Deficit/Hyperactivity Disorder) or autism may have issues processing complex language. A clear, concise language can improve readability not only for people with cognitive disabilities but also for non-native speakers. Using a bullet points and headings help here, too.

How to test?

I would like to mention first of all the build-in accessibility tools of Firefox. This can be opened when you right click on an element and open 'Inspect Accessibility Properties'. There you can check for issues of three categories: contrast, keyboard, text-labes. Also you can simulate different eye issues such as achromatopsia (no color) and see the tabbing order. Also they offer links to a great concise documentation about the found issue.

To check how the page is pronounced by screenreaders I would recommend you to install can install NVDA or JAWS on your computer. We might cover this in another article

• As mentioned before, to check the contrast between colors you can next to the Firefox accessibility tools also: Link to WebAIM Contrast Checker .
• Another easy accessibility evaluation tool is WAVE: Link to WAVE Accessibility Evaluation Tool .

Build accessibility in, don't bolt it on. Integrating accessibility from the start of development is far more effective and efficient than adding it as an afterthought.

I hope this article helped. See you soon in the next one!